（摔酒杯）為什麼敏捷式開發法這些年會被認為失敗率很高（根本不值得推薦）？

因為多數的專案是採「案主對開發方」的方式在進行，而「案主」都有個通病：他們不想參與開發過程、契約簽下去後下次跟開發方聯繫最好就是看到成品，他們頂多聽取會報然後負責一知半解的抱怨罵人，甚至拿著契約發出威脅....

「呵！進度那麼慢還有那個臉給我笑嘻嘻地走進辦公室，看我在老闆面前把他們罵一頓！」這種小人年底升官一定有份。

回來說說上一篇分享的專案。
那個飯店訂房系統專案同時還採取「敏捷式開發法」，最後變成一場大災難。（有一半以上的問題都是因為敏捷式開發法造成的。）

為什麼敏捷式開發法會這麼受歡迎或受到討論與推廣？
因為絕大多數人都不會討論或意識到的是這個年頭的資訊產品（尤其是這種客製化成分極高、但並非大量套模板複製生產）已經不再適合「開發完成度百分之百才上市」的模式了！

「什麼？你在講什麼愚蠢鬼話？沒完成的作品怎麼能給客戶用？」如果馬上這樣想的人真的很需要繼續讀我的文章，如果被氣死了提早重新投胎是你的福氣。

一個產品的理想藍圖是由很多功能組成的，但理想藍圖跟「可以發布到市場上的藍圖」是兩回事。

舉個最簡單的、最舉世轟動的例子吧！

大名鼎鼎的遊戲「暗黑破壞神」，第一代職業只有三個，還沒有技能樹，角色移動速度只有一種，甚至整個地城關卡也只有一座。
尤其一代與二代都是使用同一套遊戲技術框架模組，但一代跟二代相比差異之大，說一代是「未完成」根本也不為過。
雖然換個方向來看，二代本身也有未完成的地方，重點是一代的「未完成」根本不影響它的成功。
如果把時間推進到今天，不只軟體的發布、安裝、更新有App Market代勞，網頁也發展出了提供複雜Application的能力，今天的人如果要開發「暗黑破壞神」，肯定不會分成一代二代去獨立開發，而是將一代用免費形式發佈後，再以DLC的方式發布二代。

有稍微掌握到「敏捷式開發法」真正的成功基礎了嗎？

重點並不在你如何規劃會議頻率、會議進行形式，而是根本上，你的商業銷售策略是否有辦法分批次的把一個「功能」給銷售出去、或推廣給終端使用者。

如果能，則產品的樣貌應該要多方向彈性規劃、最終以市場反應和開發執行成果來逐一決定商品要演進的方向。（產品企劃構思會很累，但這完全是必要之惡。）

而這恰恰好是絕大多數專案形式根本做不到的事情。

所以敏捷式開發法如果會失敗，問題根本不在你的專案管理，問題在「你這個專案天生會死/被客戶殺死」。

在回題一次。

一款以飯店訂房為主打訴求的服務，不管最終形態是網頁或APP，它當初計畫的銷售形式並不是直接推廣給客戶，而是委託旅行社代為推廣，作為旅行社自己內部的線上訂房系統的新版或升級款。
白話翻譯：我從一開始就知道自己的產品在一般市場上是沒有競爭力的，必須要被捆綁在旅行社的現有商業模式下才有機會存活，但我不好意思求旅行社分享資源給我，而是假裝自己是旅行社下個世代的救世主。

有沒有旅行社上當，這就不是我關心的了，畢竟我的心思很快就被接下來一點都不敏捷的敏捷式開發會議地獄給消耗殆盡。

我理想中的旅行用APP應該要回頭走「社群交友平台」的模式，讓飯店、旅行社、旅行愛好者們可以在這平台上進行平行的互相交流。

為什麼要強調平行？
因為飯店為何要在這個平台上建立自家房型的資料呢？為何要在這個平台上幫自家的房型或特色服務做推廣呢？
當然是因為「你的平台使用便利成本低、同時有足夠的潛在客戶。」

而要怎麼建立潛在客戶群？同時後期無縫吸引企業加入？這就是「社群平台」最大的強項了！（不懂？天哪！我這是講專案管理，不是講行銷。）

當這兩項功能都達到後，然後才是考慮是否要增加「訂房功能」，在此之前，「訂房」只要用「是否要聯繫您附近的旅行社」「要幫您尋找最近的旅行社嗎？」這樣的功能就可以了！
（白話文補強：假設某人寫了篇遊記，系統會立刻在旁邊尋找文中出現的任何相關地點、飯店、旅遊行程，然後盡可能不要太粗暴的推送到閱讀遊記的人眼前。）

但，往事已成追憶。

乾杯。